在進到 Health Check Monitoring 前，先講兩個我認為在部署 Inference Service 常會遺漏的兩個事情: Error Handling 和 Latency

一個 Inference Endpoint 可能會愈倒以下幾種錯誤

• 沒有則夠的機器資源來完成一次 Inference
• 傳入的數值有錯誤，像是應該傳入的是 YYYY-MM-DD 的日期卻傳進來的 Timestamp
• 或是有無法預期的數值也從未在歷史資料出現過的數值
• 在組合特徵或是計算比例時出現分母為 0 的狀況
• 沒有定義好 null, none, ""

而這些狀況若是你都讓 Endpoint HTTP Response 500 或是回傳 200 但是是一個 Default 的 Inference Score 都會造成者個系統出現很大的問題

這裡介紹幾個經驗上的準則

1. 不要讓 Default Score 在內部使用，內不需要定義錯誤代碼
2. 正確的定義以下幾種狀況
   1. 沒有值
   2. 空值
   3. 計算錯誤的值
3. 有意義的 Response Code 很重要，非特殊情況，不要使用 200 但是在內部帶錯誤訊息
4. 用 4xx 和 5xx 來區分是 Client Error 還是 Server Error
5. 以上幾點應該整個公司的模型區要通用，別且減少有例外

區分是 Client Error 還是 Server Error

以下我們舉幾個常見範例:

• 400 Bad Request: 常用於帶入的特徵或是參數有霧
• 404 Not Found: 如果模型不存在
• 500 Internal Server Error: 模型資源不足或是內部有沒有處理到的 Exception
• 503 Service Unavailable: 模型如果是 Blocking 或是會被長時間佔用的模型，可以回傳這個表示模型存在但是目前不可用
• 另外模型還會搭配 /HealthCheck 這樣的 resource 來給調用方確認模型是否可以被正常使用

要正確的回答以上的 Status Code 好的 try-except 就非常重要，另外也需要搭配 Logger 等系統把錯誤日誌記錄下來才好快速定位問題

Timeout

另外一個比較棘手的問題是 Timeoue，也是就是 Latency 問題，有時候模型還沒有任何的 Response 但是由於 Invoke 方有時間壓力，並有設置 Request Timeout 就會出現錯誤，好的方法是去測試模型的平均 Timeout

• 可以用 JMeter, Locust 或 Artillery 可以進行更復雜的延遲測試，來模擬多用戶、多請求的情況
• 另外也會有一些常見的性能監控軟體可以分析延遲的信息: 如 Datadog, Prometheus, Grafana 等

Timeout 最好的解決方式就是上線前有壓力測試的報告和上線後的監控，有了這些才好讓 Invoke 方去評估是否需要做更多不同的處理方式，常見的處理方式除了加大機器和平行化之外，還可以用 Cache, 改資料格式如 grpc 甚至是架構上改 Polling 等等